In facilitating the handling of transactions, business entities frequently transmit business transaction data electronically in a strict format over common communications networks. For example, the electronic data interchange (EDI) is one of the ways that businesses take advantages of the ever-expanding reach of automated computing systems.
In EDI, business data is formatted according to one or more known and approved standards, such as ANSI X12 or EDIFACT. For example, the EDI data representing various transactions are transmitted as a batch of delineated documents, and each of the delineated documents is encoded according to strict formatting rules to ensure the destination application receiving the documents is able to successfully parse and consume the information for down stream processing.
In parsing and processing the EDI messages, existing systems transmit EDI data and include the formatting rules or schemas in each delineated document during the interchange. For example, the EDI data representing a purchase order transaction includes a schema for the purchase order transaction. As such, each EDI transaction document includes both the EDI data and the specific schema for the transaction. While this arrangement or configuration facilities parsing of the EDI data, it is static and makes each transaction document large in terms of document size. In addition, the included schema is not sharable. In other words, if there are two purchase order transaction documents A and B, each purchase order transaction document needs to include a purchase order schema even though the schema in each document is identical. Also, EDI transactions are charged, among other things, according to the number of lines or documents, and bandwidth needed for transmitting the EDI data. As business entities transmit millions of transactions on a daily basis using EDI, these large EDI transaction documents, which include duplicate schema information, create unnecessary costs for having redundant schema information.
Once the EDI transaction documents are received, the destination application typically stores the EDI transaction documents in a memory area. The destination application next transmits a receipt acknowledgement to the source indicating that the transactions have been received. The stored EDI transactions are thereafter validated by applications to determine whether the EDI data included in the transaction documents comply with the formatting rules of the schemas for the transaction types. During this validation time, the source (e.g., a merchant or a customer) is required to wait for a validation acknowledgement to indicate that the transaction data conforms to the format. If it is determined that one or more transactions are not formatted correctly, replacement EDI transaction documents need to be re-transmitted for processing. This waiting-for-validation delay further reduces the efficiency of processing EDI transactions.